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[57] ABSTRACT 

A method and apparatus is provided in a data processing 
system for securing access to particular files which are 
stored in a computer-accessible memory media. A file man- 
agement program is provided as an operating system com- 
ponent ofthe data processmg^stem^plurality of files 

"SiSSSffl^^Se^^, including at 
Lleast one unencrypted file. %r» 

r^fiffiSIeMnlmemD^, a decryption block is generated which 
includes information which can be utilized to decrypt the 
file, and the decryption block is incorporated in the file in 
lieu of the preselected portion which has been recorded in 
memory. Then, a file management program is utilized to 
monitor data processing system calls for file s stored in the 
computer-accessible memory media. TlSPfiTelfciaragemEnt 
program determines whether the called file has an associated 
decryption block. The called file is processed in a particular 
manner dependent upon whether or not the called file has an 
associated decryption block. 
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METHOD AND APPARATUS FOR ENABLING 
TRIAL PERIOD USE OF SOFTWARE 
PRODUCTS: METHOD AND APPARATUS 
FOR UTILIZING A DECRYPTION BLOCK 



CROSS-REFERENCE TO RELATED 
APPLICATION 

The present application is related to U.S. patent applica- 
tion Ser. No. 08/235,033, entitled "Method and Apparatus 
for Enabling Trial Period Use of Software Products: Method 
and Apparatus for Utilizing a Decryption Stub " further 
identified by Attorney Docket No. BT9-93-070; U.S. patent 
application Ser. No. 08/235,035, entitled "Method and 15 
Apparatus for Enabling Trial Period Use of Software Prod- 
ucts: Method and Apparatus for Allowing a Try-and-Buy 
User Interaction," further identified by Attorney Docket No. 
DA9-94-008; U.S. patent application Ser. No. 08/235,032, 
entitled "Method and Apparatus for Enabling Trail Period ^ 
Use of Software Products: Method and Apparatus for Gen- 
erating a Machine-Dependent Identification," further iden- 
tified by Attorney Docket No. DA9-94-009; and U.S. patent 
application Ser. No. 08/235,418, entitled •'Method and 
Apparatus for Enabling Trial Period Use of Software Prod- ^ 
ucts: Method and Apparatus for Allowing the Distribution of 
Software Objects," further identified by Attorney Docket 
No. DA9-94-01 1 , all filed on Apr 25, 1994 by the inventors 
hereof and assigned to the assignee herein, and incorporated 
by reference herein. 

' 30 
BACKGROUND OF THE INVENTION 

1. Technical Field 

^JenresenUnvention relates in general to techniques for 
^s^S^^^ess^u?s&ftwaro»ol^©ts, and in particular to 35 
yteeh^ques'Cor temporarily e^^^feg|andge^ggn||a^ss\ 
" t o^ftw^efob iegts, 

2. Description of the Related Art 

The creation and sale of software products has created 
tremendous wealth for companies having innovative prod- 
ucts, and this trend will continue particularly since consum- 
ers are becoming ever-more computer literate as time goes 
on. Computer software is difficult to market since the 
potential user has little opportunity to browse the various 
products that are available. Typically, the products are 
contained in boxes which are shrink-wrapped closed, and 
the potential customer has little or no opportunity to actually 
interact with or experience the software prior to purchasing. 
This causes considerable consumer dissatisfaction with 
products, since the consumer is frequently forced to serially 
purchase a plurality of software products until an acceptable 
product is discovered. This is perhaps one significant cause 
of the great amount of software piracy which occurs in our 
economy. A potential software purchaser will frequently 55 
"borrow" a set of diskettes from a friend or business 
associate, with the stated intention of using the software for 
a temporary period. Frequently, such temporary use extends 
for long intervals and the potential customer may never 
actually purchase a copy of the software product, and may ^ 
instead rely upon the borrowed copy. 

Since no common communication channel exists for the 
sampling of software products, such as those created in 
movie theaters by movie trailers, and in television by 
commercials, software manufacturers are forced to rely 65 
upon printed publications and direct mail advertisements in 
order to advertise new products and solicit new customers. 
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Unfortunately, printed publications frequently fail to provide 
an accurate description of the product, since the user inter- 
action with the product cannot be simulated in a static 
printed format. TTie manufacturers of computer software 
products and the customers would both be well served if the 
customers could have access to the products prior to making 
decisions on whether or not to purchase the product, if this 
could be accomplished without introducing risk of unlawful 
utilization of the product. 

The distribution of encrypted software products is one 
mechanism a software vendor can utilize to distribute the 
product to potential users prior to purchase; however, a key 
must be distributed which allows the user access to the 
product. The vendor is then forced to rely entirely upon the 
honesty and integrity of a potential customer. Unscrupulous 
or dishonest individuals may pass keys to their friends and 
business associates to allow unauthorized access. It is also 
possible that unscrupulous individuals may post keys to 
publicly-accessible bulletin boards to allow great numbers 
of individuals to become unauthorized users. Typically, 
these types of breaches in security cannot be easily pre- ' 
vented, so vendors have been hesitant to distribute, software 
for preview by potential customers. 

SUMMARY OF THE INVENTION 

It is one object of the present invention to provide a 
method and apparatus for distributing software objects from 
a producer to potential users which allows the user a 
temporary trial period without subjecting the software prod- 
uct to unnecessary risks of piracy or unauthorized utilization 
beyond the trial interval. Preferably this is accomplished by 
providing a software object on a computer-accessible 
memory media along with a file management program. 
Preferably, the software object is reversibly functionally 
limited, through one or more particular encryption opera- 
tions. The computer-accessible memory media is shipped 
from the producer to the potential user utilizing conventional 
mail and delivery services. Upon receipt, the potential user 
loads the file management program into a user-controlled 
data processing system and associates it with the operating 
system for the data processing system. Then, the computer- 
accessible memory media is read utilizing the user-con- 
trolled data processing system. The file management pro- 
gram is executed by the user-controlled data processing 
system and serves to restrict access to the software object for 
a predefined and temporary trial period. During the tempo- 
rary trial mode of operation, the software object is tempo- 
rarily enabled by reversing the reversible functional limita- 
tion of the software object. This is preferably accomplished 
by decryption of the encrypted software object when the 
software object is called by the operating system of the 
user-controlled data processing system. The file manage- 
ment program preferably prevents copying operations, so 
the encrypted software project is temporarily decrypted 
when it is called by the operating system. If the potential 
user elects to purchase the software object, a permanent use 
mode of operation is entered, wherein the functional limi- 
tation of the software object is permanently reversed, allow- 
ing unlimited use to the software object by the potential user. 
This facilitates browsing operations which allow the poten- 
tial user to review the software and detennine whether it 
sui ts hi s or her needs. 
_ jgernemsf^ 
atmg^ystcm»pfMtfae*us 
system for operating system input calls and output calls. Trie* 
file management program identifies when the orjerating 
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system of the user-controlled data processing system calls 
for a software object which is subject to trial-interval 
browsing. Then, the file management system fetches a 
temporary access key associated with the software object, 
and then examines the temporary access key to determine if 
it is valid. Next, the file management program reverses the 
functional limitation of the software object, and passes it to 
the data processing system for processing. 

It is another objective of the present invention to provide 
a method and apparatus for distributing a software object 
from a source to a user, wherein a software object is 
encrypted utilizing a long-lived encryption key, and directed 
from the source to the user. The encrypted software object is 
loaded onto a user-controlled data processing system having 
a particular system configuration. A numerical, machine 
identification based at least in part upon the particular 
configuration of the user-controlled data processing system 
is then derived. Next, a temporary key is derived which is 
based at least in part upon the numerical machine identifi- 
cation and the long-lived encryption key. A long-lived key 20 
generator is provided for receiving the temporary key and 
producing the long-lived encryption key. The temporary key 
allows the user to generate for a prescribed interval the 
long-lived encryption key to access the software object 
These operations are performed principally by a file man- 
agement program which is operable in a plurality of modes. 
These modes include a set up mode of operation, a machine 
identification mode of operation, and a temporary key deri- 
vation mode of operation. Dor4n^th^geffiui«ui0cieM(ji» 

°i 

usafeeoat rjSi^^ 
an opftratmg^yjter^ 

sy&emaB&KtBgtfth^ of opera- 

tion, the file management program is utilized to derive a 
numerical machine identification based upon at least on 
attribute of the user-controlled data processing system. Dur- 
ing the temporary key derivation mode of operation, a 
temporary key is derived which is based at least in part upon 
the numerical machine identification. The file management 
program also allows a trial mode of operation, wherein the 40 
file management program is utilized by executing it with the 
user-controlled data processing system to restrict access to 
the software object for an interval defined by the temporary 
key, during which the long-lived key generator is utilized in 
the user-controlled data processing system to provide the 45 
long-lived key in response to receipt of at least one input 
including the temporary key. 

It is yet another objective of the present invention to 
provide a method and apparatus in a data processing system 
for securing access to particular files which are stored in a 50 
comput er-accessible memory media. A^a^^nnpffTn^nt 
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. A plurality of files are stored in 

the ctmmjuue raecels iD^ 

orSKcryptea meSnd at least one unencrypted file. For each 55 

*memcH5?3*a decryption block is generated whiclHududes^ 
information which can be utilized to decrypt the file, and the 
decryption block is incorporated into the file in lieu of the 
preselected portion which has been recorded elsewhere in 60 
computer merrlol^^u^fcfikmanagement program is utilized 
to monitor data r^c^essmg^bperationscalls^^ 
siflEe^gm ^ewcajmpu t ^ maiia. The file 

management program'deteirnin^wBelfleTme called file has 
an associated decryption block. The file management pro- 65 
gram processes the called file in a particular manner depen- 
dent upon whether or not the called file has an associated 



decryption block. The incorporation of the decryption block 
does not change the size of the encrypted file, thus prevent- 
ing certain types of processing errors. During the trial 
interval, the encrypted file is maintained in an encrypted 
condition, and cannot be copied. If the potential user opts to 
purchase the software product, a permanent key is provided 
which results in replacement of the preselected portion to the 
file in lieu of the decryption block. Once the decryption 
block is removed, the encrypted file may be decrypted to 
allow unrestricted use by the purchaser. Preferably, the file 
management program is utilized to intercept files as they are 
called by the operating system, and to utilize the decryption 
block to derive a name for a key file and read the called file. 
The decryption block of each encrypted file includes a 
validation segment which is decrypted by the file manage- 
ment program and compared to a selected segment for the 
called file to determine whether the key can decrypt the 
particular file. If the decrypted validation segment matches 
a known clear text validation segment, the file is then 
dynamically decrypted as it is passed for further processing. 

It is yet anomeriobjecliveEofzthezpres ent-inv entiongto 
provide^ method and a pparatus in,ai0^ta^rjrt)cess3nfe~svstem« 
f or secSmjpicc^^ are stored in a 

c3 ragurer*are esM^ A file management 

progra% ^p*avid^ 

data processing system. m^aFeo tHputeiJai^essiblegnienioiy^ 

esei9ipted*file*Md*0M The 
encrypted file has associated with it an unencrypted security 
stub wju cjiis at least partially composed of executable code. 
The file managemenfpro^amis 1 utiliz^"tb^monrtoFmedata^» 
prc^smg^system^calls^fc^a'c^ 

^accessible memory media, to-deteanme^wnemertfee 
is*aii«a^sw£aT!S^ 
to process the called file in a particular manner dependent 
upon whether or not the called file has an associated unen- 
crypted security stub. More particularly, if it is determined 
that the called file has no associated unencrypted security 
stub, the called file is allowed to be processed. However, Lf 
it is determined that the called file has an associated unen- 
crypted security stub, it must be examined before a decision 
can be made about whether or not to allow it to be processed. 
First, the unencrypted security stub is examined in order to 
obtain information which allows decryption operations to be 
performed. Then, the decryption operations are performed. 
Finally, the called file is allowed to pass for further process- 
ing. Preferably, the called file is dynamically decrypted as it 
is passed to the operating system for processing. Also, the 
unencrypted security stub is separated from the called file 
prior to execution of the called file. However, if the unen- 
crypted security stub accidentally remains attached to the 
called file, processing operations must be stopped, and a 
message must be posted in order to prevent the processor 
from becoming locked-up. 
It is still another objective of the present invention to 
i 6v3tie»a*metliud»ai^ 

)^e^*from^^6urce^to^a*use^. rjproni nnittfa^ac^ 
memory m e ^ia is d istributed from the sourceto^potenua^^ 
usS^fruicTSie^^ 

and secret ^^f'/GtvafBHSSc program is* provided which 
facilitates interaction between the source and the user. The 
interface program includes machine identification module 
which generates a machine identification utilizing at least on 
predetermined attribute of the user-controlled data process- 
ing system. It also further includes a loll|^ivel^a^^rePk 
^ke^genemto^which receives as an input at least a temporary 
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key and produces as an output a long-lived and secret key. 
A validation module is provided which tests temporary key 
determined its validity. The source of the software object 
maintains a temporary key generator which receives as an 
input at least a machine identification and p roduces-a n 5 
output of the temporary ke y. An mt er^fee^regr^Tis loaded 
UQ the userrcontn^ied^qa^c ^gessio^ system. The 

c^gjn^svstem and to generate the machine identification. 10 
During interaction between the source and the user, the 
machine identification is communicated over an insecure 
communication channel. At the source of the software 
object, the temporary key is generated utilizing the machine 
identification (and other information) as an input to the 15 
temporary key generator. During interaction between the 
source and the user, the temporary key is communicated, 
typically over an insecure communication channel. Next, the 
validation module is utilized to determine the validity of the 
temporary key. The long-lived and secret key generator is 20 
then utilized to receive the temporary key and generate the 
long-lived and secret key in order to decrypt and temporarily 
gain access to the software object. The user is also provided 
with an import module and an export module which allow 
for the utilization of portable memory media to transfer the 25 
encrypted software object, a key file, and a machine iden- 
tification file from one machine in a distributed data pro- 
cessing system to another machine in the distributed data 
processing system, while allowing the temporary key to 
allow temporary trial access to the software object. 30 

The above as well as additional objectives, features, and 
advantages of the present invention will become apparent in 
the following detailed written description. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



The novel features believed characteristic of the invention 
are set forth in the appended claims. The invention itself, 
however, as well as a preferred mode of use, further objec- 40 
tives and advantages thereof, will best be understood by 
reference to the following detailed description of an illus- 
trative embodiment when read in conjunction with the 
accompanying drawings, wherein: 

FIG. 1 is a pictorial representation of a stand-alone data 45 
processing system, a telephone, and a variety of computer- 
accessible memory media all of which may be utilized in the 
implementation of the preferred technique of enabling trial 
period use of software products; 

FIG. 2 is a pictorial representation of a distributed data 50 
processing system which may utilize the technique of the 
present invention of enabling trial period use of software 
products; 

FIG. 3 is a block diagram representation of data process- 
ing system attributes which may be utilized to generate a 55 
machine identification, in accordance with the present 
invention; 

FIG. 4 is a block diagram depiction of a routine for 
encrypting software objects; 6Q 

FIG. 5 is a pictorial representation of the exchange of 
information between a source (a software vendor) and a user 
(a customer), in accordance with the teachings of the present 
invention; 

FIG. 6 is a flowchart representation of the broad steps 65 
employed in building a user interface shell, in accordance 
with the present invention; 



FIG. 7 is a flowchart representation of vendor and cus- 
tomer interaction in accordance with the present invention; 

FIGS. 8, 9, 10a, and lOfc depict user interface screens 
which facilitate trial period operations in accordance with 
the present invention; 

FIG. 11 depicts a user interface which is used to initiate 
a temporary access key; 

FIG. 12 is a block diagram depiction of the preferred 
technique of generating a machine identification; 

FIG. 13 is a block diagram depiction of an encryption 
operation which is utilized to encrypt a machine identifica- 
tion, in accordance with the present invention; 

FIG. 14 is a block diagram representation of the preferred 
technique for generating a product key, in accordance with 
the present invention; 

FIG, 15 is a block diagram representation of a preferred 
technique utilizing a temporary product key to generate a 
real key which can be utilized to decrypt one or more 
software objects; 

FIGS. 16 and 17 depict a preferred technique of validating 
the real key which is derived in accordance with the block 
diagram of FIG. 15; 

FIG. 18 is a block diagram depiction of the preferred 
routine for encyrpting a key file which contains information 
including a temporary product key; 

FIG, 19 is a block diagram depiction of the preferred 
technique of handling an encryption header in an encrypted 
file, in accordance with the present invention; 

FIG. 20 depicts in block diagram form the technique of 
utilizing a plurality of inputs in the user-controlled data 
processing system to derive the real key which may be 
utilized to decrypt an encrypted software object; 

FIG. 21 depicts a decryption operation utilizing the real 
key derived in accordance with FIG. 20; 

FIG. 22 is a block diagram depiction of a comparison 
operation which is utilized to determine the validity of the 
real key; 

FIG. 23 depicts a decryption operation utilizing a vali- 
dated real key; 

FIGS. 24, 25, 26, 27, 28 depict the utilization of an 
encryption header in accordance with the present invention; 

FIGS. 29A and 29B are a flowchart representation of the 
preferred technique of providing a trial period of use for an 
encrypted software object; 

FIGS. 30 and 31 depict export and import operations 
which may be utilized to perform trial period use operations 
in a distributed data processing system; 

FIGS. 32 and 33 provide an alternative view of the import 
and export operations which are depicted in FIGS, 30 and 
31; 

FIGS. 34 and 35 provide a block diagram depiction of an 
alternative technique for perf brming an export/import opera- 
tion. 



DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENT 

The method and apparatus of the present invention for 
enabling trail period use of software products can be utilized 
in stand-alone PCs such as that depicted in FIG. 1, or in 
distributed data processing systems, such as that depicted in 
FIG. 2. In either event, temporary trial period access to one 
or more software products depends upon utilization of the 
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trial product on a particular data processing system with controller 86, diskette controller 88, and disk controller 82. 
particular data processing system attributes. This is accom- Additionally, a plurality of empty or occupied slots 106 may 
plished by encrypting the trial software product utilizing a be used to identify the particular data processing system, 
temporary access key which is based upon one or more data Each particular data processing system may have attributes 
processing system attributes. FIG. 3 graphically depicts a 5 which may be derived from RAM 70, ROM 68, or CMOS 
plurality of system configuration attributes, which may be RAM 72. End devices such as printer 96, monitor 94, mouse 
utilized in developing a temporary access key, as will be 92, keyboard 90, diskette 100, or disk drive 104 may be 
described in greater detail herebelow. To begin with, the utilized to derive one or more attributes of the data process- 
environment of the stand-alone data processing system of ing system which may be processed in a predetermined 
FIG. 1, and the distributed data processing system of FIG. 2 1Q manner to derive a machine identification value. The deri- 
will be described in detail, followed by a description of vation of the machine identification value will be described 
particular system configuration attributes which are depicted in greater detail below. The present invention is directed to 
in FIG. 3. an efficient method of distributing software programs to 

With reference now to the figures and in particular with users which would provide to them a means to try the 

reference to FIG. 1, there is depicted a pictorial represen- program before obtaining (by purchasing) a license for it. In 

tation of data processing system 10 which may be pro- accordance with this concept, complete programs are dis- 

grammed in accordance with the present invention. As may tributed to potential users on computer-accessible memory 

be seen, data processing system 10 includes processor 12 me di a sucn ^ diskettes or CD-ROMs. The concept is to 

which preferably includes a graphics processor, memory generate keys that allow the user to access the programs 

device and central processor (not shown). Coupled to pro- fr 0 m the distributed media. In this environment, a file 

cessor 12 is video display 16 which may be implemented management program provides a plurality of interfaces 

utilizing either a color or monochromatic monitor, in a which allows the user to browse the different products. The 

manner well known in the art. Also coupled to processor 12 interfaces allow ordering and unlocking of the software 

is keyboard 14. Keyboard 14 preferably comprises a stan- products contained on the distributed media. Unlocking of 

dard computer keyboard which is coupled to the processor the software product is accomplished by the reception, 

by means of a cable. validation, and recording of a temporary access (decryption) 

Also coupled to processor 12 is a graphical pointing key. 

device, such as mouse 20. Mouse 20 is coupled to processor Th e fii e management program is resident?ing the=user-^ga 

12, in a manner well known in the art, via a cable. As is controlled data processing^ystem and becomes a part of the 

shown, mouse 20 may include left button 24, and right ^ operating^y^temin-the*u^r*s computer. An example of such 

button 26, each of which may be depressed, or "clicked", to " a resident program (in the PC DOS environment) would be 

provide command and control signals to data processing a resident program TSR, for '^crrninate and stay resident" 

system 10. While the disclosed embodiment of the present operations, that intercepts and handles DOS file input and 

invention utilizes a mouse, those skilled in the art will output operations. When a temporary access key is provided 

appreciate that any graphical pointing device such as a light 35 to a user, system files are checked to see if this file has been 

pen or touch sensitive screen may be utilized to implement usec j m a trial mode of operation before. If the product has 

the method of the present invention. Upon reference to the never been used in a trial mode of operation, the temporary 

foregoing, those skilled in the art will appreciate that data k ev i s saved. Once the trial mode of operation key exists, an 

processing system 10 may be implemented utilizing a so- encrypted application can only be run if it is initiated by the 

called personal computer, such as the Model 80 PS/2 com- ^ fi] e management program. The file management program 

puter manufactured by International Business Machines ^1 recognize that the application is encrypted and that a 

Corporation of Armonk, N.Y. valid trial mode of operation key exists for the particular 

\&iileithe?Dresentaflv^ operation. A valid trial mode of application key is one that 

data processing systems, it my^so;be-utilizeo^in = a^isffio- has not expired. The trial mode of operation may be defined 

ata'processing system, prowdedtmeiimp^aridiexport 45 by either a timer, or a counter. A timer can be used to count 

rofetanay&feheip^OT^ down a particular predefined period (such as thirty days); 

or more encrypted files^ Uieir^enc^p^^e^files^aHd alternatively, the counter can be used to decrement through 

associatetTlile Inanage nient pro grams^tj ^ugrf^p OT gtele a predefined number of trial "sessions" which are allowed 

memorylneBia^soefe^ during the trial mode of operation. If the key is valid, the file 

lar data processing unitswitju^weio^sffi^ 50 management program communicates directly with the TSR 

ing systera"WmTe^foe~import and export routines of the and enables the trial mode of operation for a particular 

present invention will be described in greater detail herebe- encrypted application. The file management program then 

low, it is important that a basic distributed data processing kicks off the encrypted application. The code which is 

system be described and understood. resident in the operating system of the user-controlled data 

FIG. 3 provides a block diagram depiction of a plurality 55 processing system maintains control over the operating 

of data processing system attributes which may be utilized system. It monitors the use of the trial mode of operation 

to uniquely identify a particular data processing system k evs t0 &N° W t0 be decrypted and loaded into memory, 

(whether a stand-alone or a node in a distributed data °ut prevents the encrypted files from being decrypted and 

processing system), and which further can be utilized to copied to media This is done by using the operating system 

generate in the machine identification value which is utilized 60 t0 determine which applications are trying to access the data 

to derive or generate a temporary access product key which on ty allowing the applications that have permission to 

may be utilized to gain access to an encrypted product for a access the data to do so. 

particular predefined trial interval. A data processing system FIG. 4 is a block diagram depiction of a routine for 

may include a particular system bus 60 architecture, a encrypting software objects. The binary characters which 

particular memory controller 74, bus controller 76, interrupt 65 make up software object 201 are supplied as an input to 

controller 78, keyboard mouse controller 80, DMA control- encryption engine 205. Real key 203 is utilized as an 

ler66, VGA video controller 82, parallel controller 84, serial encryption key in encryption engine 205. The output of 
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encryption engine 205 is an encrypted software object 207. 
Encryption engine 205 may be any conventional encryption 
operation such as the . published and well known DES 
algorithm; alternatively, the encryption engine 205 may be 
an exclusive-OR operation which randomizes software 5 
object 201. 

FIG. 5 is a pictorial representation of the exchange of 
information between a source 209 (a software vendor) and 
a user 211 (a potential customer, in accordance with the 
teachings of the present invention. Trie arrows between 10 
source 209 and user 211 represent exchanges of objects or 
information between vendor 209 and 211. In the exchange of 
flow 203, computer-accessible memory media is directed 
from source 209 to user 211. This transfer may occur by US 
mail delivery, courier delivery, express service delivery, or 15 
by delivery through printed publications such as books and 
magazines. Alternatively, an electronic document may be 
transferred from source 209 to user 211 utilizing electronic 
mail or other transmission techniques. In flow 215, user- 
specific information, preferably including a unique machine 2Q 
identification number which identifies the data processing 
system of user 211, is transferred from user 211 to source 
209 via an insecure communication channel; typically, this 
information is exchanged over the telephone, but may be 
passed utilizing electronic mail or other communication ^ 
techniques. In flow 217, source 209 provides a product key 
to user 211. Hie product key allows the product contained in 
the memory media to be temporarily accessed for a pre- 
scribed and predefined interval. This interval is considered 
to be a "trial" interval during which user 211 may become 3Q 
familiar with the software and make a determination on 
whether or not he or she wishes to purchase the software 
product. User 211 must communicate additionally with 
source 209 in order to obtain permanent access to the 
software product. The product key allows user 211 to obtain 35 
access to the software product for a particular predefined 
time interval, or for a particular number of predefined 
"sessions." As time passes, the user's clock or counter runs 
down. At the tennination of the trial period, further access is 
denied. Therefore, the user 211 must take affirmative steps ^ 
to contact source 209 and purchase a permanent key which 
is communicated to user 211 and which permanently 
unlocks a product to allow unrestricted access to the soft- 
ware product. 

The communication between source 209 and user 211 is 45 
facilitated by a user interface. The creation of the interface 
is depicted in flowchart form in FIG. 6. The process begins 
at software block 219, and continues at software block 221, 
wherein source 209 makes language and locale sections 
which will determine the language and currencies utilized in 50 
the interlace which facilitates implementation of the trial 
period use of the software products. A plurality of software 
products may be bundled together and delivered to user 211 
on a single computer-accessible memory media. Therefore, 
in accordance with software block 223, source 209 must 55 
make a deterrnination as to the programs which will be made 
available on a trial basis on the computer-accessible memory 
media, and the appropriate fields are completed, in accor- 
dance with software block 223. Next, in accordance with 
software block 225, the programs are functionally limited or go 
encrypted Then, in accordance with software block 227, the 
shell is loaded along with the computer program products 
onto a computer-accessible memory media such as a diskette 
or CD ROM. The process ends at software block 229. • 

FIG. 7 is a flowchart representation of vendor and cus- 65 
tomer interaction in accordance with the present invention. 
The flow begins at software block 231, and continues at step 



233, wherein computer-accessible memory media are dis- 
tributed to users for a try-and-buy trial interval. Then, in 
accordance with step 235, the file management program is 
loaded from the computer-accessible memory media onto a 
user-controlled data processing system for execution. The 
file management program includes a plurality of interface 
screens which facilitate interaction between the vendor and 
the customer, which and which set forth the options avail- 
able to the customer. Thus, in accordance with step 237, the 
file management program allows browsing and displays 
appropriate user interfaces. Next, in accordance with step 
239, the customer and the vendor interact, typically over the 
telephone or electronic mail, to allow the vendor to gather 
information about the customer and to distribute a temporary 
key which allows access to one or more software products 
which are contained on the computer-accessible memory 
media for a predefined trial interval. Typically, the interval 
will be defined by an internal clock, or by a counter which 
keeps track of the number of sessions the potential purchaser 
has with a particular software product or products. Step 241 
represents the allowance of the trial interval use. Then, in 
accordance with software block 243, the file management 
program monitors and oversees all input and output calls in 
the data processing system to prevent unauthorized use of 
the encrypted software products contained on the computer- 
accessible memory media In the preferred embodiment of 
the present invention, the file management program moni- 
tors for calls to encrypted files, and then determines whether 
access should be allowed or denied before the file is passed 
for further processing. The customer can assess the software 
product and determine whether he or she desires to purchase 
it. If a decision is made to purchase the product, the 
customer must interact once again with the vendor, and the 
vendor must deliver to the customer a permanent key, as is 
set forth in step 245. The process ends when the customer 
receives the permanent key, decrypts the one or more 
software products that he or she has purchased, and is then 
allowed ordinary and unrestricted access to the software 
products. 

FIGS. 8, 9, 10a, and 10b depict user interface screens 
which facilitate trial period operations in accordance with 
the present invention. FIG. 8 depicts an order form user 
interface 249 which is displayed when the customer selects 
a "view order" option from another window. The order form 
user interface 249 includes a title bar 251 which identifies 
the software vendor and provides a telephone number to 
facilitate interaction between the potential customer and the 
vendor. An order form field 255 is provided which identifies 
one or more software products which may be examined 
during a trial interval period of operation. A plurality of 
subfields are provided including quantity subfield 259, item 
subfield 257, description subfield 260, and price subfield 
253. Delete button 261 allows the potential customer to 
delete items from the order form field. Subtotal field 263 
provides a subtotal of the prices for the ordered software. 
Payment method icons 265 identify the acceptable forms of 
payment. Of course, a potential user may utilize the tele- 
phone number to directly contact the vendor and purchase 
one or more software products; alternatively, the user may 
select one or more software products for a trial period mode 
of operation, during which a software product is examined 
to fetermine its adequacy. A plurality of function icons 267 
are provided at the lowermost portion of order form inter- 
face 249. These include a close icon, fax icon, mail icon, 
print icon, unlock icon, and help icon. The user may utilize 
a graphical pointing device in a conventional point- and-click 
operation to select one or more of these operations. Hie fax 
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icon facilitates interaction with the vendor utilizing a fac- 
simile machine or facsimile board. The print icon allows the 
user to generate a paper archival copy of the interaction with 
the software vendor. 

The customer, the computer-accessible memory media, 5 
and the computer system utilized by the customer are 
identified by media identification 269, customer identifica- 
tion 273, and machine identification 271. The media iden- 
tification is assigned to the computer-accessible memory 
media prior to shipping to the potential customer. It is fixed, 10 
and cannot be altered. The customer identification 273 is 
• derived from interaction between the potential customer and 
the vendor. Preferably, the customer provides answers to 
selected questions in a telephone dialogue, and the vendor 
supplies a customer identification 273, which is unique to * 5 
the particular customer. The machine identification 271 is 
automatically derived utilizing the file management program 
which is resident on the computer-accessible memory 
media, and which is unique to the particular data processing 
system being utilized by the potential customer. The poten- 20 
tial customer will provide the machine identification to the 
vendor, typically through telephone interaction, although fax 
interaction and regular mail interaction is also possible. 

FIG. 9 is a representation of an order form dialog interface 
275. This interface facilitates the acquisition of information 25 
which uniquely identifies the potential customer, and 
includes name field 277, address field 279, phone number 
field 281, facsimile number field 283, payment method field 
285, shipping method field 287, account number field 289, 
expiration date field 291, value added tax ID field 293. Order 30 
information dialog interface 275 further includes print but- 
ton 295 and cancel button 297 which allow, the potential user 
to delete information from these fields, or to print a paper 
copy of the interface screen. 

FIGS. 10a and lQb depict unlock dialog interface screens 
301, 303. The user utilizes a graphical pointing device to 
select one or more items which are identified by the content 
item number field 307 and description field 309 which are 
components of unlock list 305. The interface further 
includes customer ID field 313 and machine ID field 315. 
Preferably, the vendor provides the customer identification 
to the customer in an interaction via phone, fax, or mail. 
Preferably, the customer provides to the vendor the machine 
identification within machine identification field 315 during 45 
interaction via phone, fax, or mail. Once the information is 
exchanged, along with an identification of the products 
which are requested for a trial interval period of operation, 
a temporary access key is provided which is located within 
key field 311. The key will serve to temporarily unlock the 5Q 
products identified and selected by the customer. Close 
button 319, save button 317, and help button 321 are also 
provided in this interface screen to facilitate user interaction. 

FIG. 10b depicts a single-product unlock interface screen 
303.. This interface screen includes only machine identifi- 55 
cation field 315, customer identification field 315, and key 
field 311. The product which is being unlocked need not be 
identified in this interface, since the dialog pertains only to 
a single product, and it is assumed that the user knows the 
product for which a temporary trial period of operation is so 
being requested. Save button 317, cancel button 319, and 
help button 321 are also provided in this interface to 
facilitate operator interaction. 

FIG. 11 depicts a user interface screen which is utilized in 
unlocking the one or more encrypted products for the 65 
commencement of a trial interval mode of operation. The 
starting date dialog of FIG. 11 is displayed after the "SAVE" 



35 



40 



push button is selected in the unlock dialog of either FIG. 
10a or FIG. 10b. The user will be prompted to verify the 
correct starting date which is provided in date field 310. The 
user responds to the query pointing and clicking to either the 
"continue" button 312, the "cancel" button 314, or the 
"help" button 316. The date displayed in field 310 is derived 
from the system clock of the user-controlled data processing 
system. The user may have to modify the system clock to 
make the date correspond to the official or stated date of 
commencement of the trial period of operation. 

A trial interval operation can take two forms: one form is 
a functionally disabled product that allows a user to try all 
the features, but may not allow a critical function like 
printing or saving of data files. Another type of trial interval 
is a fully functional product that may be used for a limited 
time. This requires access protection, and allows a customer 
to try all the functions of a product for free or for a nominal 
fee. Typically, in accordance with the present invention, 
access to the product is controlled through a 'limed" key. 
The trial period for using the product is a fixed duration 
•determined by the vendor. The trial period begins when the 
key is issued. In accordance with the present invention, the 
products being previewed during the trial interval of opera- 
tion can only be run from within a customer shell. A 
decryption driver will not allow the encrypted products to be 
copied in the clear, nor will it allow the product to be run 
outside the customer's shell. In an alternative embodiment, 
the trial interval is defined by a counter which is incremented 
or decremented with each "session" the customer has with 
the product This may allow the customer a predefined 
number of uses of the product before decryption is no longer 
allowed with the temporary key. 

The limits of the temporary access key are built into a 
"control vector" of the key. Typically, a control vector will 
include a short description of the key, a machine identifi- 
cation number, and a formatted text string that includes the 
trial interval data (such as a clock value or a counter value). 
The control vector cannot be altered without breaking the 
key. When a protected software product, is run, the usage 
data must be updated to enforce the limits of the trial interval 
period of operation. In order to protect the clock or counter 
from tampering, its value is recorded in a multiple number 
of locations, typically in encrypted files. In the preferred 
embodiment of the present invention, the trial interval 
information (clock value and/or counter value) is copied to 
a "key file" which will be described in further detail her- 
ebelow, to a machine identification file, which will also be 
discussed herebelow, and to a system file. When access to an 
encrypted program is requested, all of these locations are 
checked to determine if the value for the clock and/or 
counter is the same. It is unlikely that an average user has the 
sophistication to tamper successfully with all three files. In 
the preferred embodiment, a combination of a clock and a 
counter is utilized to prevent extended use of backup and 
restore operations to reset the system clock. Although it is 
possible to reset a PC's clock each time a trial use is 
requested, this can also be detected by tracking the date/time 
stamps of certain files on the system and using the most 
recent date between file date/time stamps and the system 
clock. As stated above, one of the three locations the timer 
and/or counter information is stored is a system file. When 
operating in an OS/2 operating system, the time and usage 
data can be stored in the system data files, such as the 
OS2.INI in the OS/2 operating system. The user will have to 
continuously backup and restore these files to reset the trial 
and usage data. These files contain other data that is sig- 
nificant to the operation of the user system. The casual user 



11/13/2003, EAST Version: 1.4.1 



5,598 

13 

can accidentally lose important data for other applications 
by restoring these files to an older versioa In the present 
invention, these protection techniques greatly hinder a dis- 
honest user* s attempts to extend the trial interval use beyond 
the authorized interval. 5 

In broad overview, in the present invention, the vendor 
loads a plurality of encrypted software products onto a 
computer-accessible memory media, such as a CD ROM or 
magnetic media diskette. Also loaded onto the computer- 
accessible memory media is a file management program 10 
which performs a plurality of functions, including the func- 
tion of providing a plurality of user interface screens which 
facilitate interaction between the software vendor and the 
software customer. The computer-accessible memory media 
is loaded onto a user-controlled data processing system, and 15 
the file management program is loaded for execution. The 
file management program provides a plurality of user- 
interface screens to the software customer which gathers 
information about the customer (name, address, telephone 
number, and billing information) and receives the customer 20 
selections of the software products for which a trial interval 
is desired. Information is exchanged between the software 
vendor card customer, including: a customer identification 
number, a product identification number, a media identifi- 
cation number, and a machine identification number. The 25 
vendor generates the customer identification number in 
accordance with its own internal record keeping. Preferably, 
the representative of the software vendor gathers informa- 
tion from the software customer and types this information 
into a established blank form in order to identify the poten- 30 
tial software customer. Alternatively, the software vendor 
may receive a facsimile or mail transmission of the com- 
pleted order information dialog interface screen 275 (of FIG, 
9). The distributed memory media (such as CDs and dis- 
kettes) also include a file management program which is 35 
used to generate a unique machine identification based at 
least in part upon one attribute of the user-controlled data 
processing system. This machine identification is preferably 
a random eight-bit number which is created during a one- 
time setup process. Preferably, eight random bits are gen- 40 
erated from a basic random number generator using the 
system time as the "seed" for the random number generator. 
Preferably, check bits are added in the final result Those 
check bits are critical to the order system because persons 
taking orders must key in the machine ID that the customer 45 
reads over the phone. The check bits allow for instant 
verification of the machine ID without requiring the cus- 
tomer to repeat the number. Preferably, a master file is 
maintained on the user-controlled data processing system 
which contains the clear text of the machine identification 5u 
and an encrypted version of the machine identification. 

When the software customer places an order for a tem- 
porary trial use of the software products, he or she verbally 
gives to the telephone representative of the software vendor 
the machine identification. In return, the telephone repre- 55 
sentative gives the software customer a product key which 
serves as a temporary access key to the encrypted software 
products on the computer-accessible memory media, as well 
as a customer identification number. Preferably, the product 
key is a function of the machine identification, the customer 60 
number, the real encryption key for the programs or pro- 
grams ordered, and a block of control data. The software 
customer may verify the product key by combining it with 
the customer number, and an identical block of control data 
to produce the real encryption key. This key is then used to 65 
decrypt an encrypted validation segment, to allow a compare 
operation. If the encrypted validation segment is identical to 
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known clear text for the validation segment, then the user's 
file management program has determined that the product 
key is a good product key and can be utilized for temporary 
access to the software products. Therefore, if the compare 
matches, the key is stored on the user-controlled data 
processing system in a key file. Preferably, the key file 
contains the product key, a customer key (which is generated 
from the customer number and an internal key generating 
key) and a clear ASCII string containing the machine 
identification. All three items must remain unchanged in 
order for the decryption tool to derive the real encryption 
key. To further tie the key file to this particular user- 
controlled data processing system, the same key file is 
encrypted with a key that is derived from system parameters. 
These system parameters may be derived from the configu- 
ration of the data processing system. 

Stated broadly, in the present invention the temporary key 
(which is given verbally over the phone, typically) is created 
from an algorithm that utilizes encryption to combine the 
real key with a customer number, the machine identification 
number, and other predefined clear text. Thus, the key is 
only effective for a single machine: even if the key were to 
be given to another person, it would not unlock the program 
on that other person's machine. This allows the software 
vendor to market software programs by distributing com- 
plete programs on computer-accessible memory media such 
as.diskettes or CD ROMs, without significant risk of the loss 
of licensing revenue. 

Some of the preferred unique attributes of the system 
which may be utilized for encryption operations include the 
hard disk serial number, the size land format of the hard disk, 
the system model number, the hardware interface cards, the 
hardware serial number, and other configuration parameters. 
The result of this technique is that a machine identification 
file can only be decrypted on a system which is an identical 
clone of the user-controlled data processing system. This is 
very difficult to obtain, since most data processing systems 
have different configurations, and the configurations can 
only be matched through considerable effort. These features 
will be described in detail in the following written descrip- 
tion. 

Turning now to FIG. 12, the file management program 
receives the distributed computer-accessible memory media 
with encrypted software products and a file management 
program contained therein. The file management program 
assesses the configuration of the user-controlled data pro- 
cessing system, as represented in step 351 of FIG. 12. The 
user-specific attributes of the data processing system are 
derived in step 353, and provided as an input to machine 
identification generator 355, which is preferably a random 
number generator which receives a plurality of binary char- 
acters as an input, and generates a pseudo-random output 
which is representative of machine identification 357. The 
process employed by machine identification generator 355 is 
any conventional pseudo-random number generator which 
receives as an input of binary characters, and produces as an 
output a plurality of pseudo-random binary characters, in 
accordance with a predefined algorithm. 

With reference now to FIG. 13, machine identification 
357 is also maintained within the file management program 
in an encrypted form. Machine identification 357 is supplied 
as an input to encryption engine 359 to produce as an output 
the encrypted rnachine identification 361. Encryption engine 
359 may comprise any convention encryption routine, such 
as the DES algorithm, A key 363 is provided also as an input 
to encryption engine 359, and impacts the encryption opera- 
tion in a conventional manner. Key 363 is derived from 
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system attribute selector 365. The types of system attributes 
which are candidates. for selection include system attribute 
listing 367 which includes: the hard disk serial number, the 
size of the hard disk, the format of the hard disk, the system 
model number, the hardware interface card, the; hardware 5 
serial number, or other configuration parameters. 

In accordance with the present invention, the clear text 
machine identification 357 and the encrypted machine iden- 
tification 361 are maintained in memory. Also, in accordance 
with the present invention, the file management program 10 
automatically posts the clear text machine identification 357 
to the appropriate user interface screens. The user then 
communicates the machine identification to the software 
vendor where it is utilized in accordance with the block 
diagram of FIG. 14. As is shown, product key encryption 
engine 375 is maintained within the control of the software 
vendor. This product key encryption engine 375 receives as 
an input: the machine identification 357, a customer number 
369 (which is assigned to the customer in accordance with 
the internal record keeping of this software vendor), the real 
encryption key 371 (which is utilized to decrypt the software 20 
products maintained on the computer-accessible memory 
media within the custody of the software customer), a 
control block text 373 (which can be any predefined textural 
portion), and trial interval data 374 (such as clock and/or 
counter value which defines the trial interval of use). Product 25 
key encryption engine produces as an output a product key 
377. Product key 377 may be communicated to the software 
customer via an insecure communication channel, without 
risk of revealing real key 371. Real key 371 is masked by the 
encryption operation, and since the product key 377 can only ^ 
be utilized on a data processing system having a configu- 
ration identical to that from which machine identification 
357 has been derived, access to the encrypted software 
product is maintained in a secure condition. 

Upon delivery of product key 377, the file management 35 
program resident in the user-controlled data processing 
system utilizes real key generator 379 to receive a plurality 
of inputs, including product key 377, customer number 369, 
control block text 373, machine identification 357 and trial 
interval data 374. Real key generator 379 produces as an ^ 
output the derived real key 381. 

Encryption and decryption algorithm utilized to perform 
the operations of the product key encryption engine 375 and 
the real key generator 379 (of FIGS. 14 and 15) is described 
and claimed in co-pending U.S. patent application Ser. No. 45 
07/964,324, filed Oct 21, 1992, entitled "Method and Sys- 
tem for Multimedia Access Control Enablement", which is 
incorporated herein as if fully set forth. 

Next, as is depicted in FIGS. 16 and 17, the derived real 
key 381 is tested to determine the validity and authenticity 50 
of the product key 377 which has been provided by the 
software vendor. As is shown, the derived real key 381 is 
supplied as an input to encryption engine 385. A predeter- 
mined encrypted validation data segment 383 is supplied as 
the other input to encryption engine 385. Encryption engine 55 
supplies as an output derived clear validation text 387. Then, 
in accordance with FIG. 17, the derived clear validation text 
387 is compared to the known clear validation text 391 in 
comparator 389. Comparator 389 simply performs a bit-by- 
bit comparison of the derived clear validation text 387 with 60 
the known clear validation text 391. If the derived clear 
validation text 387 matches the known clear validation text 
391, a key file is created in accordance with step 393; 
however, if the derived clear validation text 387 does not 
match the known clear validation text 391, a warning is 65 
posted to the user-controlled data processing system in 
accordance with step 395. 



Turning now to FIG. 18, key file 397 is depicted as 
including the temporary product key, the customer key 
(which is an encrypted version of the customer number), the 
machine identification number in clear text and the trial 
interval data (such as a clock and/or counter value). This key 
file is supplied as an input to encryption engine 399. Key 401 
is also provided as an input to encryption engine 399. Key 
401 is derived from unique system attributes 403, such as 
those system attributes utilized in deriving the machine; 
identification number. Encryption engine 399 provides as an 
output the encrypted key file 405. 

FIGS. 19, 20, 21, 22, and 23 depict operations of the file 
management program after a temporary access key has been 
received, and validated, and recorded in key file 397 (of FIG. 
18). 

FIG. 19 is a block diagram representation of the steps 
which are performed when an encrypted software product is 
called for processing by the user-control data processing 
system. The encrypted file 405 is fetched, and a "header" 
portion 407 is read by the user-controlled data processing 
system. The header has a number of components including 
the location of the key file. The location of the key file is 
utilized to fetch the key file in accordance with step 409. The 
header further includes an encrypted validation text 411. The 
encrypted validation text 411 is also read by the user- 
controlled data processing system. As is stated above (and 
depicted in FIG. 18) the key file includes the product key 
419, a customer key 417, and the machine identification 415. 
These are applied as inputs to decryption engine 413. 
Decryption engine 413 provides as an output real key 421. 
Before real key 421 is utilized to decrypt encrypted software 
products on the distributed memory media, it is tested to 
determine its validity. FIG. 21 is a block diagram of the 
validation testing. Encrypted validation text 423, which is 
contained in the "header 1 ', is provided as an input to decryp- 
tion engine 425. Real key 421 (which was derived in the 
operation of FIG. 20) is also supplied as an input to 
decryption engine 425. Decryption engine 425 provides as 
an output clear validation text 427. As is set forth in block 
diagram form in FIG. 22, clear validation text 427 is 
supplied as an input to comparator 429. The known clear 
validation text 431 is also supplied as an input to comparator 
429. Comparator 429 deterrnines whether the derived clear 
validation text 427 matches the known clear validation text 
431. If the texts match, the software object is decrypted in 
accordance with step 433; however, if the validation text 
portions do not match, a warning is post in accordance with 
step 435. FIG. 23 is a block diagram depiction of the 
decryption operation of step 433 of FIG. 22. The encrypted 
software object 437 is applied as an input to decryption 
engine 439. Hie validated real key 441 is also supplied as an 
input to decryption engine 439. Decryption engine 439 
supplies as an output the decrypted software object 443. 

The encryption header is provided to allow for the deter- 
mination of whether or not a file is encrypted when that file 
is stored with clear-text files. In providing the encryption 
header for the encrypted file, it is important that the file size 
not be altered because the size may be checked as part of a 
validation step (unrelated in any way to the concept of the 
present invention) during installation. Therefore, making the 
file larger than it is suppose to be can create operational 
difficulties during installation of the software. The encryp- 
tion header is further necessary since the file names asso- 
ciated with the encrypted software products cannot be 
modified to reflect the fact that the file is encrypted, because 
the other software applications that may be accessing the 
encrypted product will be accessing those files utilizing the 
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original file names. Thus, altering the file name to indicate 
that the file is encrypted would prevent beneficial and 
desired communication between the encrypted software 
product and other, perhaps related, software products. For 
example, spreadsheet applications can usually port portions 
of the spreadsheet to a related word processing program to 
allow the integration of financial information into printed 
documents. Changing the hard-coded original file name for 
the word processing program would prevent the beneficial 
communication between these software products. The 
encryption header of the present invention resolves these 
problems by maintaining the encrypted file at its nominal file 
length, and by maintaining the file name for the software 
product in an unmodified form. 

FIG. 24 graphically depicts an encrypted file with encryp- 
tion header 451. The encryption header 451 includes a 
plurality of code segments, including: unique identifier 
portion 453, the name of the key file portion 455, encrypted 
validation segment 457, encryption type 459, offset to side 
file 461, and encrypted file data 463. Of course, in this view, 
the encrypted file data 463 is representative of the encrypted 
software product, such as a word processing program or 
spreadsheet. The encryption header 451 is provided in place 
of encrypted data which ordinarily would comprise part of 
the encrypted software product. The encryption header is 
substituted in the place of the first portion of the encrypted 
software product. In order to place the encryption header 
451 at the front of the encrypted software product of 
encrypted file data 463, a portion of the encrypted file data 
must be copied to another location. Offset to side file 461 
identifies that side file location where the displaced file data 
is contained 

FIG. 25 graphically depicts the relationship between the 
directory of encrypted files and the side files. As is shown, 
the directory of encrypted files 465 includes file aaa, file bbb, 35 
file ccc, file ddd, through file nnn. Bach of these files is 
representative of a directory name for a particular encrypted 
software product. Each encrypted software product has 
associated with it a side file which contains the front portion 
of the file which has been displaced to accommodate encryp- 40 
tion header 451 without altering the size of the file, and 
without altering the file name. File aaa has associated with 
it a side file AAA. Software product file bbb has associated 
with it a side file BBB. Encrypted software product ccc has 
associated with it a side file CCC. Encrypted software 45 
product ddd has associated with it a side file DDD. 
Encrypted software product nnn has associated with it a side 
file NNN. In FIG. 25, directory names 467, 469, 471, 473, 
475 are depicted as being associated with side files 477, 479, 
481, 483, and 485. The purpose of the side files is to allow 50 
each of the encrypted software products to be tagged with an 
encryption header without changing the file size. 

Encryption type segment 459 of the encryption header 
451 identifies the type of encryption utilized to encrypt the 
encrypted software product Any one of a number of con- 55 
ventional encryption techniques can be utilized to encrypt 
the product, and different encryption types can be utilized to 
encrypt different software products contained on the same 
memory media. Encryption type segment 459 ensures that 
the appropriate encryption/decryption routine is called so 60 
that the encrypted software product may be decrypted, 
provided the temporary access keys are valid and not 
expired. The name of key file segment 455 of encryption 
header 451 provides an address (typically a disk drive 
location) of the key file. As is stated above (in connection 65 
with HG. 18) the key file includes the product key, a 
customer key, and the clear machine ID. All three of these 
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pieces of information are required in order to generate the 
real key (in accordance with FIG. 20). Encrypted validation 
segment 457 includes the encrypted validation, text which is 
utilized in the routine depicted in FIG. 21 which generates 
a derived clear validation text which may be compared 
utilizing the routine of FIG. 22 to the known clear validation 
text. Only if the derived clear validation text exactly matches 
the known clear validation text can the process continue by 
utilizing the derived and validated real key to decrypt the 
encrypted software product in accordance with the routine of 
FIG. 23. However, prior to performing the decryption opera- 
tions of FIG. 23, the contents of the corresponding side file 
must be substituted back into the encrypted software product 
in lieu of encryption header 451. This ensures that the 
encrypted software product is complete prior to the com- 
mencement of decryption operations. 

Each time a file is called for processing by the operating 
system of the user-controlled data processing system, the file 
management program which is resident in the operating 
system intercepts the input/output requests and examines the 
front portion of the file to determine if a decryption block 
identifier, such as unique identifier 453, exists at a particular 
known location. For best performance, as is depicted in FIG. 
24, this location will generally be at the beginning of the file. 
If the file management program determines that the file has 
the decryption block, the TSR will read the block into 
memory. The block is then parsed in order to build a fully 
qualified key file name by copying an environment variable 
that specifies the drive and directory containing the key files 
and concatenating the key file name from the encryption 
block. The TSR then attempts to open the key file. If the key 
file does not exist, the TSR returns an "access denied" 
response to the application which is attempting to open the 
encrypted file. If the key file is determined to exist, the TSR 
opens the key "file and reads in the keys (the product key, the 
customer key, and the machine identification) and generates 
the real key. This real key is in use to decrypt the decryption 
block validation data. As is stated above, a comparison 
operation determines whether this decryption operation was 
successful. If the compare fails, the key file is determined to 
be "invalid", and the TSR returns an "access denied mes- 
sage" to the application which is attempting to open the 
encrypted software product However, if the compare is 
successful, the file management program prepares to decrypt 
the file according to the encryption type found in the 
encryption header. The TSR then returns a valid file handle 
to the calling application to indicate that the file has been 
opened. When the application reads data from the encrypted 
file, the TSR reads and decrypts this data before passing it 
back to the application. If the data requested is part of the 
displaced data that is stored in the side file, the TSR will read 
the side file and return the appropriate decrypted block to the 
calling application without the calling application being 
aware that the data came from a separate file. 

While the broad concepts of the encryption header are 
depicted in FIGS. 24 and 25, the more particular aspects of 
creating the encrypted files are depicted in FIGS. 26, 27, and 
28. FIGS. 27 and 28 depict two types of data files. FIG. 27 
depicts a non-executing data file, while FIG. 28 depicts, an 
executing data file. FIG. 26 depicts a header 499 which 
includes signature segment 501, header LEN 503, side file 
index 505, side file LEN 507, decryption type identifier 509, 
verification data 511, and key file name 518,. As is shown in 
FIG. 27, a software product begins as a clear file 521, and 
is encrypted in accordance with a particular encryption 
routine into encrypted file 523. Encryption type segment 509 
of header 499 identifies the type of encryption utilized to 
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change clear file 521 to encrypted file 523. Next, the front 
portion of encrypted file 523 is copied to side file 527 which 
is identified by side file index 505 and side file LEN 507 of 
header 499. Additionally, a copy of the clear text of the 
verification data is also included in side file 527. Then, 
header 499 is copied to the front portion of encrypted file 
523 to form modified encrypted files 525. A similar process 
is employed for executing files, as depicted in FIG. 28. The 
clear text copy of the software product (represented as clear 
file 531) is encrypted in accordance with a conventional 
routine, to form encrypted file 533. The front portion of 
encrypted file 533 is copied to side file 539 so that the 
overlaid data of encrypted file 533 is preserved. Further- 
more, side file 539 includes a copy of the dear text of the 
verification data. Then, the encrypted file 533 is modified by 
overlaying and executable stub 537 and header 599 onto the 
first portion of encrypted file 553. 

The purpose of executable stub 537 of FIG. 28 will now 
be described. The DOS operating system for a personal 
computer will try to execute an encrypted application. This 
can result in a system "hang" or unfavorable action. The 
executable stub 357 of the executing file of FIG. 28 is 
utilized to protect the user from attempting to execute 
applications that are encrypted: there would be considerable 
risk that a user would hang his system or format a drive if 25 
he or she try to run an encrypted file. The executable stub is 
attached to the front portion of the encrypted software 
product so that this stub is executed whenever the applica- 
tion is run without the installed TSR or run from a drive the 
TSR is not "watching". This stub will post a message to the 
user that explains why the application cannot run. In addi- 
tion to providing a message, this executable stub can be used 
to perform sophisticated actions, such as: 

(1) it can duplicate the functionality of the TSR and install 
dynamic encryption before kicking off the application 
a second time; 

(2) it can turn on a temporary access key and kick off the 
application a second time; 

(3) it can communicate with the TSR and inform it to look 
at the drive the application is being run from. 

The executable stub is saved or copied into the encrypted 
program as follows: 

(1) the application is encrypted; 

(2) a decryption block is created for this program; 

(3) a pre-built executable stub is attached to the front end 
of the decryption block; 

(4) the length of the combined decryption header and 
executable stub is determined; 

(5) the bytes at the front of the executable file equal to this 
length are then read into memory, preferably into a 
predefined side file location; and 

(6) the encryption header and executable stub are then 
written over the leading bytes in the executable code. 

The TSR can determine if an executable is encrypted by 
searching beyond the "known size" of the executable stub 
for the decryption block portion. When the TSR decrypts the 
executable stub it accesses the side file to read in the bytes 
that were displaced by the stub and header block. 

FIGS. 29A and 29B provide a flowchart representation of 
operation during a trial period interval, which begins at 
software block 601. In accordance with software block 603, 
the file management program located in the operating sys- 
tem of the user-controlled data processing system continu- 
ally monitors for input/output calls to the memory media. 
Then, in accordance with software block 605, for each 
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input/output call, the called file is intercepted, and in accor- 
dance with software block 607 the operating system is 
denied access to the called file, until the file management 
program can determine whether access should be allowed or 
not. A portion of the called file is read where the decryption 
block should be located. This portion of the called file is then 
read, in accordance with software block 609, to derive a key 
file address in accordance with software block 611. The 
address which is derived is utilized to fetch the key file, in 
accordance with software block 613. In accordance with 
decision block 615, if the key file cannot be located, the 
process ends at software block 617; however, if it is deter- 
mined in decision block 615 that the key file can be located, 
the key is derived in accordance with software block 619. 
The derived key is then utilized to decrypt the validation 
segment which is located within the encryption header, in 
accordance with software block 621. In decision block 623, 
the decryption validation segment is compared to the clear 
text for the decryption validation segment; if it is determined 
that the decrypted segment does not match the known clear 
text segment, the process continues at software block 625 by 
ending; however, if it is determined in decision block 623 
that the decrypted validation segment does match the known 
clear text validation segment, the process continues as 
software block 627, wherein access to the called file is 
allowed. Then, the decryption type is read from the decryp- 
tion header in accordance with software block 629, and the 
called file is dynamically decrypted in accordance with 
software block 631 as it is passed for processing by the 
operating system of the user-controlled data processing 
system, in accordance with software block 633. The process 
terminates at software block 635. 

If unauthorized execution of an encrypted file is 
attempted, the executable stub will at least temporarily deny 
access and post a message to the system, but may handle the 
problem in a number of sophisticated ways which were 
enumerated above. 

In accordance with the preferred embodiment of the 
present invention, during the trial interval, or at the conclu- 
sion of the trial interval, the prospective purchaser may 
contact the vendor to make arrangements for the purchase of 
a copy of the one or more software products on the com- 
puter-accessible memory media. Preferably, CD ROMs or 
floppy disks have been utilized to ship the product to the 
potential user. Preferably, the computer-accessible memory 
media includes the two encrypted copies of each of the 
products which are offered for a trial interval of use. One 
encrypted copy may be decrypted utilizing the file manage- 
ment program and the temporary key which is communi- 
cated from the vendor to the purchaser. The other encrypted 
copy is not provided for use in the trial interval mode of 
operation, but instead is provided as the permanent copy 
which may be decrypted and utilized once the software 
product has been purchased. In broad overview, the user 
selects a software product for a trial interval mode of 
operation, and obtains from the vendor temporary access 
keys, which allow the user access to the product (through the 
file management program) for a predefined trial interval. 
Before or after the conclusion of the trial interval, the user 
may purchase a permanent copy of the software product 
from the vendor by contacting the vendor by facsimile, 
electronic mail, or telephone. Once payment is received, the 
vendor communicates to the user a permanent access key 
which is utilized to decrypt the second encrypted copy of the 
software product. This encrypted product may be encrypted 
utilizing any conventional encryption routine, such as the 
DES algorithm. The permanent key allows the software 
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product to be decrypted for unrestricted use. Since multiple 
copies of the product may be purchased in one transaction, 
the present invention is equipped with a technique for 
providing movable access keys, which will be discussed 
below in connection with FIGS. 30 through 35. In the 
preferred embodiment of the present invention, the encryp- 
tion algorithm employed to encrypt and decrypt the second 
copy of the software product is similar to that employed in 
the trial interval mode of operation. 

The present invention includes an export/import function 
which allows for the distribution of permanent access keys, 
after the conclusion of a trial interval period. Typically, an 
office administrator or data processing system manager will 
purchase a selected number of "copies" of the encrypted 
product after termination of a trial interval period. Certain 
individuals within the organization will then be issued 
permanent keys which allow for the unrestricted and per- 
manent access to the encrypted product. In an office or work 
environment where the computing devices are not connected 
in a distributed data processing network, the permanent 
access keys must be communicated from the office admin- 
istrator or data processing manager to the selected individu- 
als within an organization who are going to receive copies 
of the encrypted software product. The permanent keys 
allow for permanent access to the product Since not all 
employees within an organization may be issued copies of 
the particular encrypted product, the vendor would like to 
have the distribution occur in a manner which minimizes or 
prevents the distribution beyond the sales agreement or 
license agreement. Since the products are encrypted, they 
may be liberally distributed in their encrypted form. It is the 
keys which allow unrestricted access to the product which 
are to be protected in the current invention. To prevent the 
distribution of keys on electronic mail or printed commu- 
nications, the present invention includes an export program 
which is resident in a source computer and an import 
program which is resident in a target computer which allow 
for the distribution of the access keys via a removable 
memory media, such as a floppy diskette. This ensures that 
the access keys are not subject to inadvertent or accidental 
distribution or disclosure. There are two principal embodi- 
ments which accomplish this goal. 

In the first embodiment, one or more encrypted files 
which are maintained in the source computer are first 
decrypted, and then encrypted utilizing an encryption algo- 
rithm and an encryption key which is unique to the trans- 
portable memory media (such as a diskette serial number). 
The key file may then be physically carried via the diskette 
to a target computer, where it is decrypted utilizing a key 
which is derived by the target computer from interaction 
with the transferable memory media. Immediately, the key 
file or files are then encrypted utilizing an encryption 
operation which is keyed with a key which is derived from 
a unique system attribute of the target computer. 

In the alternative embodiment, the transferrable memory 
media is loaded onto the target computer to obtain from the 
target computer import file a transfer key which is uniquely 
associated with the target computer, and which may be 
derived from one or more unique system attributes of the 
target computer. The memory media is then transferred to 
the source computer, where the one or more key files are 
decrypted, and then encrypted utilizing the transfer key. The 
memory media is then carried to the target computer where 
the transfer key. is generated and utilized in a decryption 
operation to decrypt the one or more key files. Preferably, 
immediately the key files arc encrypted utilizing an encryp- 
tion operation which is keyed with a key which is uniquely 
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associated with the target computer, and which may be 
derived from one or more unique computer configuration 
attributes. The first embodiment is discussed herein in 
connection with FIGS. 30, 31, 32, and 33. The second 
5 embodiment is discussed in connection with FIGS. 34 and 
35. 

FIGS. 30 and 31 depict in block diagram form export and 
import operations which allow an authorized user to move 
his permanent key to another data processing system using 

10 an "export" facility that produces a unique diskette image of 
the access key that has been enabled for import into another 
system. In accordance with the present invention, the access 
keys which are delivered over the telephone by the software 
vendor to the customer are less than 40 bytes in length. The 

15 key file that is produced is over 2,000 bytes in length. An 
export facility is provided for copying the key file and the 
machine identification file to a diskette. Both files are then 
encrypted with a modified diskette serial number to inhibit 
these files from being copied to a public forum where 

20 anyone could use them. An import facility provided in 
another system decrypts these files and adds the product key 
and machine identification from the diskette to a list of 
import product keys and machine identifications in the 
import systems master file, and copies the key file to the 

25 import system hard disk. The key file is encrypted on the 
import system as is disclosed above. 

FIG. 30 is a block diagram depiction of an export opera- 
tion in accordance with the preferred embodiment of the 
present invention. As is shown, source computer 651 

30 includes a key file 653 and a machine identification file 655. 
Key file 653 includes the product key, the customer key, the 
clear text of the machine identification for source computer 
653, trial interval data (such as a clock and/or counter which 
define the trial interval period), and an export counter which 

35 performs the dual functions of defining the maximum num- 
ber of export operations allowed for the particular protected 
software products and keeping track of the total number of 
export operations which have been accomplished. The 
machine identification file includes the machine identifica- 

40 tion number and trial interval data (such as a clock and/or 
counter which defines the trial interval period). Both key file 
653 and machine identification file 655 are encrypted with 
any conventional encryption operation (such as the DES 
algorithm), which is keyed with a key which is derived from 

45 a unique system attribute of source computer 651. At the 
commencement of an export operation, key file 653 and 
machine identification file 655 are decrypted. Key file 653 is 
supplied as an input to decryption operation 657 which is 
keyed with key 659. Likewise, machine identification file 

50 655 is supplied as an input to decryption operation 663 
which is keyed with key 661. Decryption operations 657, 
663 generate a clear text version of key file 653 and machine 
identification file 655. Once the clear text is obtained, the 
export counter which is contained within key file 653 is 

55 modified in accordance with block 661. For example, if this 
is the seventh permitted export operation out of ten permis- 
sible operations, the counter might read "7:10". The clear 
text version of key file 653 is supplied as an input to 
encryption operation 669. Encryption operation 669 may be 

60 any conventional encryption operation (such as the DES 
algorithm), which is keyed with a memory media attribute 
665 which is unique to a memory media which is coupled to 
source computer 651, which has been subjected to modifi- 
cation of modifier 667. For example, a unique diskette serial 

65 number may be supplied as the "memory media attribute" 
which is unique to memory media 677. The diskette serial 
number is modified in accordance with modifier 667 to alter 
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it slightly, and supply it as an input to encryption operations 
669. The same operation is performed for the clear text of 
machine identification file 655. A unique memory media 
attribute 671 is modified by modifier 673 and utilized as a 
key for encryption operation 675, which may comprise any 5 
conventional encryption operation, such as the DES opera- 
tion. Finally, the output of encryption operations 669 and 
675 are supplied as inputs to copy operations 679, 681 which 
copy the encrypted key file 653 and machine identification 
file 655 to memory media 677. 10 

FIG. 31 is a block diagram depiction of an import 
operation. Memory media 677 (of FIG. 30) is physically 
removed from source computer 651 (of FIG. 30) and physi- 
cally carried over to computer 707 (of FIG. 31); alterna- 
tively, in a distributed data processing system, this transfer 15 
may occur without the physical removal of memory media 
677. With reference now to FIG. 31, in accordance with 
block 683, the machine identification of the target machine 
is copied to memory media 677 to maintain a record of 
which particular target computer received the key file and 20 
machine identification file. Then, in accordance with blocks 
685, 693 the encrypted key file 653 and machine identifi- 
cation file 655 are copied from the memory media to target 
computer 707. The encrypted key file 653 is supplied as an 
input to decryption operation 689 which is keyed with key 25 
687. Decryption operation 689 reverses the encryption 
operation of block 669, and provides as an output a clear text 
version of key file 653. Likewise, machine identification file 
655 is supplied as an input to decryption operation 697, 
which is keyed with key 695. Decryption operation 697 30 
reverses the encryption of encryption operation 675 and 
provides as an output the clear text of machine identification 
file 655. In accordance with block 691, the machine iden- 
tification of the source computer 651 is retrieved and 
recorded in memory in the clear text of key file 653. Next, 35 
the clear text of key file 653 is supplied as an input to 
encryption operation 699. Encryption operation 699 is a 
conventional encryption operation, such as the DES opera- 
tion, which is keyed with a target computer unique attribute, 
such as the machine identification or modified machine 40 
identification for the target computer 707. The clear text of 
machine identification file 655 is supplied as an input to 
encryption operation 703. Encryption operation 703 is any 
conventional encryption operation, such as the DES encryp- 
tion operation, which is keyed with a unique target computer 45 
attribute 705, such as machine identification or modified 
machine identification of target computer 707. The output of 
encryption operation 699 produces an encrypted key file 709 
which includes a product key (which is the same temporary 
product key of key file 653 of source computer 651), a 50 
customer number (which is the same customer number of 
key file 653 of source computer 651), and clear machine 
identification (which is the machine identification for target 
computer 707, and not that of source computer 651), trial 
interval data (which is identical to the trail interval data of 55 
key file 653 of source 651), and an identification of the 
machine, identification of the source computer 651. The 
output of encryption operation 703 defines machine identi- 
fication file 711, which includes the machine identification 
of the target computer 707 (and not that of the source 60 
computer 651), and the trial interval data (which is identical 
to that of machine identification file 655 of source computer 
651). 

FIGS. 32 and 33 provide alternative views of the import 
and export operations which are depicted in FIGS. 30 and 65 
31, and emphasize several of the important features of the 
present invention. As is shown, source computer 801 
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includes machine identification file 803 which is encrypted 
with a system attribute key which is unique to the source 
computer 801. The machine identification file includes 
machine identification file number as well as count of the 
number of exports allowed for each protected software 
product, and a count of the total number of exports which 
have been utilized. For example, the first export operation 
carries a count of "1:10", which signifies that one export 
operation of ten permitted export operations has occurred. In 
the next export operation, the counter is incremented to 
"2:20" which signifies that two of the total number of ten 
permitted export operations has occurred. Each target com- 
puter which receives the results of the export operation is 
tagged with this particular counter value, to identify that it 
is the recipient of a particular export operation. For example, 
one source computer system may carry a counter value of 
"1:10", which signifies that it is the recipient of the first 
export operation of ten permitted export operations. Yet 
another target computer may carry the counter value of 
"7:10", which signifies that this particular target computer 
received the seventh export operation of a total of ten 
permitted export operations. In this fashion, the target com- 
puter maintains a count of a total number of used export 
operations, while the source computers each carry a different 
counter value which identifies it a the recipient of the 
machine identification file and key file from the source 
computer from particular ones of the plurality of permitted 
export operations. 

Note mat in source computer 801 machine identification 
file 803 and key file 805 are encrypted with an encryption 
algorithm which utilizes as a key a system attribute which is 
unique to source computer 801; however, once machine 
identification file 803 and key file 805 are transferred to a 
memory media, such as export key diskette 807, machine 
identification file 809 and key file 811 are encrypted in any 
conventional encryption operation which utilizes as an 
encryption key a unique diskette attribute, such as the 
diskette's serial number. This rrtinimizes the possibility that 
the content of the machine ID file 809 and/or key file 811 can 
be copied to another diskette or other memory media anS 
then utilized to obtain unauthorized access to the software 
products. This is so because for an effective transfer of the 
content of machine, ID file 809 and key file 811 to a target 
computer to occur, the target computer must be able to read 
and utilize the unique diskette attribute from the export key 
diskette 807. Only when the machine ID file 809 and key file 
811 are, presented to a target computer on the diskette onto 
which these items were, copied can an effective transfer 
occur. The presentation of the machine ID file 809 and key 
file 811 on a diskette other than export key diskette 807 to 
a potential target computer will result in the transfer of 
meaningless information, since the unique attribute of 
export key diskette 807 (such as the diskette serial number) 
is required by the target computer in order to successfully 
accomplish the decryption operation. 

As is shown in FIG. 33, export key diskette 807 is 
presented to target computer 813. Of course, the machine 
identification file 809 and key file 811 are in encrypted form. 
In the transfer from export key diskette 807 to target 
computer 813, the content of machine ID file 809 is updated 
with the machine identification of the target computer 813, 
and the count of imports utilized. In accomplishing the 
transfer to target computer 813, a machine identification file 
815 is constructed which includes a number of items such as 
machine identification for the target computer 813, customer 
information, as well as a list of the machine identification 
number of the source computer 801. Both machine identi- 
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fication file 815 and the key file 817 are encrypted utilizing 
a conventional encryption operation which uses as a key a 
unique attribute of target computer 813. This ties machine 
identification file 815 and key file 817 to the particular target 
computer 813. 5 

By using an export/import counter to keep track of the 
total number of authorized export/import operations, and the . 
total number of used export/import operations, the present 
invention creates an audit trail which can be utilized to keep 
track of the distribution of software products during the trial 10 
interval. Each source computer will carry a record of the 
total number of export operations which have been per- 
formed. Each source computer will carry a record of which 
particular export/import operation was utilized to transfer 
one or more protected software products to the target com- 15 
puter. The memory media utilized to accomplish the transfer 
(such as a diskette, or group of diskettes) will carry a 
permanent record of the machine identification numbers of 
both the source computer and the target computer's utilized 
in all export/import operations. 20 

The procedure for implementing export and import opera- 
tions ensures that the protected software products are never 
exposed to unnecessary risks. When the machine identifi- 
cation file and key file are passed from the source computer 
to the export diskette, they are encrypted with the unique 25 
attribute of the export diskette which prevents or inhibits 
copying of the export diskette or posting of its contents to a 
bulletin board as a means for illegally distributing the keys. 
During the import operations, the machine identification and 
key files are encrypted with system attributes which are 30 
unique to the target computer to ensure that the software 
products are maintained in a manner which is consistent 
with the security of the source computer, except that those 
software products are encrypted with attributes which are 
unique to the target computer, thus preventing illegal copy- 35 
ing and posting of the keys. 

The second embodiment of the export/import function is 
depicted in block diagram form in FIGS. 34 and 35. In broad 
overview, memory media 1677 is first utilized to interact 
with target computer 1707 to obtain from target computer 40 
1707 a transfer key which is unique to target computer 
11707, and which is preferably derived from one or more 
unique system attributes of taTget computer 1707. The 
transfer key may be a modification of the machine identi- 
fication for target computer 1707. Next, the memory media 45 
1677 is utilized to interact with source computer 1651 in an 
export mode of operation, wherein key file 1653 and 
machine identification file 1655 are first decrypted, and then 
encrypted utilizing the transfer key. 

FIG. 34 is a block diagram depiction of an export opera- 50 
tion in accordance with the preferred embodiment of the 
present invention. As is shown, source computer 1651 
includes a key file 1653 and a machine identification file 
1655. Key file 1653 includes the product key, the customer 
key, the clear text of the machine identification for source 55 
computer 1653, trial interval data (such as a clock and/or 
counter which define the trial interval period), and an export 
counter which performs the dual functions of defining the 
maximum number of export operations allowed for the 
particular protected software products and keeping track of 60 
the total number of export operations which have been 
accomplished. The machine identification file includes the 
machine identification number and trial interval data (such 
as a clock and/or counter which defines the trial interval 
period). Both key file 1653 and machine identification file 65 
1655 are encrypted with any conventional encryption opera- 
tion (such as the DES algorithm), which is keyed with a key 
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which is derived from a unique system attribute of source 
computer 1651. At the commencement of an export opera- 
tion, key file 1653 and machine identification file 1655 are 
decrypted. Key file 1653 is supplied as an input to decryp- 
tion operation 1657 which is keyed with key 1659. Like- 
wise, machine identification file 1655 is supplied as an input 
to decryption operation 1663 which is keyed with key 1661. 
Decryption operations 1657, 1663 generate a clear text 
version of key file 1653 and machine identification file 1655, 
Once the clear text is obtained, the export counter which is 
contained within key file 1653 is modified in accordance 
with block 1661. For example, if this is the seventh permit- 
ted export operation out of ten permissible operations, the 
counter might read "7: 10". The clear text version of key file 
1653 is supplied as an input to encryption operation 1669. 
Encryption operation 1669 may be any conventional encryp- 
tion operation (such as the DES algorithm), which is keyed 
with the transfer key 1665 which was previously obtained. 
The same operation is performed for the clear text of 
machine identification file 1655. Transfer key 1671 is uti- 
lized as a key for encryption operation 1675, which may 
comprise any conventional encryption operation, such as the 
DES Operation. Finally, the output of encryption operations 
1669 and 1675 are supplied as inputs to copy operations 
1679, 1681 which copy the encrypted key file 1653 and 
machine identification file . 1655 to memory media 1677. 

FIG. 35 is a block diagram depiction of an import 
operation. Memory media 1677 (of FIG. 34) is physically 
removed from source computer 1651 (of FIG. 34) and 
physically carried over to computer 1707 (of FIG. 35); 
alternatively, in a distributed data processing system, this 
transfer may occur without the physical removal of memory 
media 1677. With reference now to FIG. 35, in accordance 
with block 1683, the machine identification of the target 
machine is copied to memory media 1677 to maintain a 
record of which particular target computer received the key 
file and machine identification file. Then, in accordance with 
blocks 1685, 1693 the encrypted key file 1653 and machine 
identification file 1655 are copied from the memory media 
to target computer 1707. The encrypted key file 1653 is 
supplied as an input to decryption operation 1689 which is 
keyed with key 1687. Decryption operation 1689 reverses 
the encryption operation of block 1669, and provides as an 
output a clear text version of key file 1653. Likewise, 
machine identification file 1655 is supplied as an input to 
decryption operation 1697, which is keyed with key 1695. 
Decryption operation 1697 reverses the encryption of 
encryption operation 1675 and provides as an output the 
clear text of machine identification file 1655. In accordance 
with block 1691, the machine identification of the source 
computer 1651 is retrieved and recorded in memory in the 
clear text of key file 1653. Next, the clear text of key file 
1653 is supplied as an input to encryption operation 1699. 
Encryption operation 1699 is a conventional encryption 
operation, such as the DES operation, which is keyed with 
a target computer unique attribute, such as the machine 
identification or modified machine identification for the 
target computer 1707. The clear text of machine identifica- 
tion file 1655 is supplied as an input to encryption operation 
1703. Encryption operation 1703 is any conventional 
encryption operation, such as the DES encryption operation, 
which is keyed with a unique target computer attribute 1705, 
such as machine identification or modified machine identi- 
fication of target computer 1707. The output of encryption 
operation 1699 produces an encrypted key file 1709 which 
includes a product key (which is the same temporary product 
key of key file 1653 of source computer 1651), a customer 
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number (which is the same customer number of key file 
1653 of source computer 1651), and clear machine identi- 
fication (which is the machine identification for target com- 
puter 1707, and not that of source computer 11651), trial 
interval data (which is identical to the trail interval data of 5 
key file 1653 of source 165l£ and an identification of the 
machine identification of the source computer 1651. The 
output of encryption operation 1703 defines machine iden- 
tification file 1711, which includes the machine identifica- 
tion of the target computer 1707 (and not that of the source 10 
computer 1651), and the trial interval data (which is iden- 
tical to that of machine identification file 1655 of source 
computer 1651). 

While the invention has been particularly shown and 
described with reference to a preferred embodiment, it will 15 
be understood by those skilled in the art that various changes 
in form and detail may be made therein without departing 
from the spirit and scope of the invention. 

We claim: 

1. A method in a data processing system of securing 20 
access to particular files which are stored in a computer- 
accessible memory media, comprising the method steps of: 

providing a file management program as an operating 
system component of said data processing system; 

storing a plurality of files including at least one encrypted 25 
file and at least one unencrypted file in said computer- 
accessible memory media; 

for each of said at least one encrypted file: 

(a) recording in said computer-accessible memory ^ 
media a preselected portion of said at least one 
encrypted file; 

(b) generating a decryption block which includes infor- 
mation which can be utilized to decrypt said at least 
one encrypted file; 35 

(c) inserting said decryption block in said at least one 
encrypted file in the place of said preselected por- 
tion; 

...utilizing said file management program to (a) monitor 
data processing system calls for a called file stored in 40 
said computer-accessible memory media, and (b) deter- 
mine whether said called file has an inserted decryption 
block, and (c) process said called file in one manner if 
said called file has an inserted decryption block, and 
process said called file in a different manner if said 45 
called file does not have an inserted decryption block. 

2. A method according to claim 1: 

wherein each of said at least one encrypted file has a 
particular file size; 
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wherein insertion of said decryption block does not 
change said particular file size for each of said at least 
one encrypted file. 

3. A method according to claim 1, further comprising: 
inserting said preselected portion in said at least one 

encrypted file in the place of said decryption block 
following expiration of a specific interval, wherein said 
interval defines a customer trial period; and 
decrypting said at least one encrypted file. 

4. A method according to claim 1, wherein said step of 
generating a decryption block comprises: 

combining (a) a unique identifier for each of said at least 
one encrypted file, with at least (b) an address to said 
preselected portion for each of said at least one 
encrypted file. 

5. A method according to claim 1, wherein said step of 
generating a decryption block comprises: 

combining (a) a unique identifier for each of said at least 
one encrypted file, with at least (b) a name for a key file 
which contains decryption keys for each of said at least 
one encrypted file. 

6. A method according to claim 1, wherein said step of 
generating a decryption block comprises: 

combining (a) a unique identifier for each of said at least 
one encrypted file, with at least (b) a validation segment 
comprising an encrypted segment of each of said at 
least one encrypted file. 

7. A method according to claim 1, wherein said step of 
generating a decryption block comprises: 

combining (a) a unique identifier for each of said at least 
one encrypted file, with at least (b) an identifier of 
which particular one of a plurality of available encryp- 
tion operations has been utilized to encrypt said at least 
one encrypted file. 

8. A method according to claim 1, wherein said step of 
utilizing said file management program to process said 
called file comprises intercepting said called file and at least 
one of: 

(a) utilizing said decryption block to retrieve a name for 
a key file and reading a key for said called file; 

(b) decrypting a validation segment of said decryption 
block, and comparing said decrypted validation seg- 
ment to a selected segment of said called file, and 
continuing operations only if said decrypted validation 
segment matches said selected segment; and 

(c) decrypting said called file at the same time as it is 
passed for further processing. 

***** 
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